NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/1412

Text File | 1996-08-06 | 3.2 KB | 108 lines

Path: news.th-darmstadt.de!news!enno
From: [e-mail] (Enno Sandner)
Newsgroups: comp.lang.c++
Subject: Re: locking
Date: 10 Jan 1996 21:33:29 GMT
Organization: Fachbereich Informatik, TH Darmstadt
Distribution: world
Message-ID: <[e-mail]>
References: <4d0j6r$[e-mail]>
    <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: kitz.intellektik.informatik.th-darmstadt.de
In-reply-to: [e-mail]'s message of 10 Jan 1996 18:30:13 GMT

In article <[e-mail]> [e-mail] (Nitin More [CONTRACTOR]) writes:

   In article <[e-mail]> Enno Sandner <[e-mail]> writes:

   > From: Enno Sandner <[e-mail]>

   [deleted]

   > >
   > > This seems to work, but the LockObject is only destroyed at the
   > > end of the block, locking my object for too long.
   > >
   > > main()
   > > {
   > >
   > >         SharedObject<foo> fooH("lock");
   > >
   > >         ... the lock is not set
   > >
   > >         fooH->bar();
   > >
   > >         .. the lock is set until the end.
   > > }
   > >
   > > Anyone got an idea ?
   > >
   >
   > I would say the temporary object should be destroyed directly after
   > the invocation of 'bar'.
   > As a workarround you can put the member-function call in brackets, e.g.
   >
   >             { foo->bar(); }
   >
   >     Enno

   You need to put the declaration of fooH also in the block as follows:

       {
       SharedObject<foo> fooH("lock");
       fooH->bar();
       .. the lock is set until the end **OF THE BLOCK**
       }
       .. fooH is destructed at the end of the block releasing the lock.

The original poster proposes an approach that builds upon chaining wrapper
classes. He has a class 'LockObject' the maintains the lock-state of a
specific object:

    template<class T> class LockObject {
       public:
        LockObject(T* o) : object(o) { lock(); }
        ~LockObject() { unlock(); }
        T* operator -> () { return object; }
        ...
            T* object;
        };

and a class that delegates method invocations to the appropriate member-
functions. The trick is that he doesn't return the object directly but
wraps it in an instance of 'LockObject'. Thus it's guaranteed that the lock
exists before the member-function is called and will be removed sometimes
after the member-function has been invoked.

    template<class T> class SharedObject {
            ...
        LockObject<T> operator -> () {
        return LockObject<T>(object);
        }
            ...
       T* object;
    };

For the class

    struct Foo { void bar(); }

a method-invocation like:

    Foo f;
    SharedObject<Foo> s(&f);
    s->bar(); // (1)

results in

      ((s.operator->()).operator->())->bar(); // = (1)

IMHO, the 'LockObject' temporary created in this expression should be
destroyed after this line. To force this behavior from an unwilling
compiler (;-) one can put (1) in brackets. So the brackets are used to
restrict the lifetime of the temporary and not the one of the SharedObject
instance.

    Enno